home *** CD-ROM | disk | FTP | other *** search
- Path: thor.tu.hac.com!collins
- From: collins@thor.tu.hac.com (Ron Collins)
- Newsgroups: alt.msdos.programmer,comp.lang.c
- Subject: Re: Two C problems
- Followup-To: alt.msdos.programmer,comp.lang.c
- Date: 18 Jan 1996 13:57:56 GMT
- Organization: Advanced Depot Systems
- Message-ID: <4dljl4$qj3@hacgate2.hac.com>
- References: <4cojnn$rgd@lugb.latrobe.edu.au> <DLCz57.5wD@ridgecrest.ca.us>
- NNTP-Posting-Host: thor.tu.hac.com
-
- Drock (drock@owens.ridgecrest.ca.us) wrote:
- : csigjb@luxor.latrobe.edu.au () wrote:
-
-
-
- : >This program should exit such that the screen is clear with the DOS prompt
- : >in the upper left corner, but no, it exits with a short line of text on the
- : >first line and then the DOS prompt on the next line. I never (or rarely)
- : >have these sort of problems with Pascal so why do they continuously crop up
- : >with C.
-
- : Well, I'm not sure why this happens but there is a couple colutions:
-
- : The Ugly way:
- : Use the borland graphic interface to capture the data on the screen
- : before anything happens in the program. Then restore the buffer upon
- : exit. In c++, this can be done using a constructor/destructor. The
- : only problem is, If you are using Borland, then you have to use their
- : BGI drivers. THEY SUCK!!!!!!!
-
- This is your professional opinion?
-
- : The clean way. Write yourself a cool little routine that stores the
- : contents of the active page. This can be done with a pointer that is
- : assigned an absolute address to video memory and treating it as an
- : array. Then just use the same array to restore what the screen to it's
- : original status upon exit. look up
-
- I thought the original poster wanted a CLEAN screen, not the ORIGINAL
- screen returned.
-
- : >PROBLEM 2 :
-
- : >const escape=27;
- : >const cr=13;
- : >const bs=8;
-
- : >while (ch!=cr)
- : >{
- : > .
- : > .
- : > .
- : >}
-
- : >while (ch!=escape)
- : >{
- : > .
- : > .
- : > .
- : >}
-
- : >If I replace the 27 with \27' or the 13 with '\13' then these loops don't
- : >work i.e. an infinite loop results. WHY?
-
- : >Also if I want to do somthing like this : puts("\24 \25"); which should
- : >print the up and down arrows on the screen (ASCII 24 and 25), but no, it
- : >prints some other ASCII characters. As far as I can tell C has its own
- : >unique character table, at least for the control characters. WHY?
-
- : >Sometimes I wonder whether some one needs to go back an rewrite the damn
- : >language so that it works sensibly and predictably like Pascal can be
- : >relied upon to do.
-
- : Because when you actually press the esc key, it's ASCII value is 27,
- : using /27 refers to esc when using the printf stuff. The /13 is
- : evaluated in those particular functions but I don';t think they are
- : evaluated when doing a straight compare. This has happened to me
- : before. If you do a printf and use /13, you get a CR , but if you read
- : in a CR, you get 13. Think about it, it's only a byte value and should
- : be treated as such.
-
- No. I have no idea what you are talking about here, but it's wrong.
-
- The tokens "13" and "\13" (note the reverse slash) refer to two
- different va
- -- Collins --
-
- -----
- The views expressed here are mine alone.
-
- Ron Collins/Hughes Aircraft Company/M20,P20/Tucson Az 85706
- rcollins@thor.tu.hac.com collins@seagull.rtd.com
- ยก----
- lues. The token "13" is a decimal thirteen, which (as it
- happens) is the ASCII ordinal value for a carraige-return. The token
- "\13" is an _octal_ eleven, which is ASCII vertical-tab, or control-K.
-
- The reverse-slash notation is used within strings (using either octal
- notation \ooo or hex notation \xhhh) simply because it is a convenient
- method of putting otherwise non-printable characters inside a string.
-
-